The present invention relates to systems and methods for simultaneous collaboration.
Many current collaboration and “versioning” tools have limitations. In the simplest example, such collaborative tools will have one user “lock” a file or group of files, preventing other users from making changes until someone, usually the original user, “unlocks” the file. This unlocking may be done manually by the user or automatically by the software they are using. This system of locks works well when the likelihood of any two users wanting to edit the same file at the same time is small, but becomes cumbersome and even prohibitive as this likelihood increases. It can also be problematic when manual unlocking is required and users forget to unlock files they are done working on.
Another technique, used in many software revision control systems (AKA Software Configuration Management Systems), is to allow all users to edit a file while checking for conflicting changes when the users save their changes to the central “repository.” A conflicting change, in this case, is any change that affects the same file, or the same section of the same file. This works well for expert systems where users are capable of comparing the data manually and dealing with the conflicts themselves, and when conflicts are unlikely. However, the system does not work well for arbitrary binary data where conflicts are hard to understand and resolve, or situations where non-experts are using the system.
Neither of these techniques is adequate for real-time collaboration, because they involve manipulation of entire files. For real-time collaboration a technique is required that does not demand the transfer of entire files and can work with a wide variety of data-types, including binary data. Moreover, we would like to minimize the possibility of conflicts, and allow for easy resolution of conflicts on the occasions that they do occur.
It is possible to extend the above techniques such that instead of files, we work with relatively small chunks of data, such as database entries, which together form a complete set of data. This complete set may appear to the user to be a file, so, to avoid confusion, we will call the complete set a document. This technique may be more than adequate for implementing many types of documents, such as a simple spreadsheet, where each cell in the table corresponds to a database entry, and each chunk of data can be locked while one user is editing it. This allows other users to edit other entries without risk of conflict, and in some cases, this is sufficient. The risk of two users wanting to edit the same entry at the same time has been reduced simply because the granularity has been improved. This system can be further improved upon in straightforward ways, if necessary: for example, locks can timeout if the UI on the machine which has the lock is idle; users can request locks from each other if someone has a lock that they need, or administrators can override locks as needed. This overcomes some of the obstacles; however, there are still cases where edits to the document may affect large amounts of data in the database, or the complexity of the data-structures is limited by the need to segregate “lockable” items, where this technique has significant limitations. In our spreadsheet example, moving multiple cells, though possible with multiple locks, becomes difficult. More difficult are operations such as inserting table rows and columns and formatting multiple cells. This design does not lend itself well to formats such as text documents where insertion and deletion constantly change the structure of the document. Therefore, the document design is dependent on the collaboration technique and may be limited in complexity. Another issue with this technique is the delay between requesting the lock and obtaining it, which must be very short in order for this technique to be convenient and user-friendly.
One possible solution is to send change information and have each client transform that information into a form that is relevant to its current state, even if its current state is different from the state of the original client. While this solution, and its extensions, called Operational Transformation (OT) is a well-established and highly developed art, it does have at least two drawbacks: 1. OT requires either the development of a large number of transformation functions, or it requires all edits to be reduced to a small number of extremely elementary edits, and 2. OT assumes that the document data can be represented in a linear fashion. While the second condition is almost always possible to meet, it is not always practical for documents with complex structures, for example, documents with complex embedded dictionaries.